Клиент
ООО «Электрорешения» (торговая марка EKF) занимается разработкой, производством и продажей электрооборудования и комплексных энергоэффективных решений для промышленных предприятий. EKF сотрудничает с крупнейшими российскими корпорациями нефтегазовой промышленности, производственными, логистическими и транспортными компаниями, а её продукция реализуется в 20 странах. Масштаб бизнеса постоянно увеличивается, что неизбежно отражается на его IT-ландшафте: растёт объём данных, курсирующих между системами, и число интеграций.
Задача: обеспечить актуальные данные во всех системах и отказоустойчивость архитектуры
Команда EKF хотела предупредить проблемы масштабирования своей IT-архитектуры. По мере увеличения объёма используемых данных могли возникнуть следующие сложности:
- долгая выгрузка обновлений в данных — лаг между обновлением информации и её поступлением во все системы-потребители начал оказывать негативное влияние на бизнес-процессы компании;
- затянутость обнаружения, разбора и решения проблем в передаче данных между системами;
- утрата или несвоевременная актуализация данных.
Команда EKF пришла к выводу о необходимости внедрения брокера сообщений Kafka, которому предстояло доверить передачу данных между системами и контроль качества доставки информации.
С этой задачей EKF обратились к KT.Team.
Опрашивая команду EKF в ходе предпроектного этапа, KT.Team уточнила запрос клиента: наладить процесс обеспечения актуальности данных во всех системах и добиться отказоустойчивости IT-архитектуры.
Такую задачу действительно можно решить с помощью внедрения ESB-слоя (не одного брокера сообщений). Однако для того чтобы в новой архитектуре не возникали перечисленные проблемы, необходимо правильно спланировать логику интеграций.
Поэтому совместно с клиентом мы разделили проект на два этапа:
- этап аналитики и планирования;
- этап внедрения.
Решение: спроектировать внедрение ESB безопасно, контролируемо и с понятным бизнес-результатом
Результат 1: выделили зоны ответственности систем
Предыдущий опыт работы KT.Team на проектах по внедрению ESB показал, что зачастую в компаниях отсутствует актуальная и полная карта потоков и интеграций as is. Каждый руководитель направления и ведущий IT-специалист экспертно понимает, как выстроены взаимосвязи конкретно в его направлении и конкретно с его системой. Об остальных фрагментах карты интеграций они имеют общее представление, которое позволяет взаимодействовать с другими подразделениями.
Отсутствие полной карты as is некритично для организации. Однако ее наличие даст IT-подразделению единый достоверный источник знаний о возможных слабых местах действующей архитектуры, способах предотвратить проблемы и возможных путях улучшения архитектуры обменов.
Поэтому первые 10 встреч с командой EKF мы посвятили построению и уточнению схемы as is. В рамках этой схемы зафиксировали зоны ответственности всех систем, которые включёны в контур EKF.
В ходе предпроектного исследования команда EKF обозначила вместе с KT.Team, какая из систем является источником для конкретного типа информации, а какая — получателем. Это позволило определить места, в которых информация могла дублироваться или противоречить сведениям в системе-источнике. Снижение скорости обмена информацией могла спровоцировать возникновение дополнительных проблем.
Кроме того, консультанты KT.Team выделили процессы с механизмом попадания информации в систему-получатель через несколько сторонних систем. Такие процессы были подвержены отказам и ошибкам больше остальных, а разбор связанных с ними инцидентов требовал серьёзных временны́х затрат.
Результат 2: команда клиента синхронизировала понимание, в каком состоянии находится IT-контур компании
Каждый из ключевых IT-специалистов EKF на момент старта проекта обладал глубокой экспертизой по своему участку работы, однако полной, достоверной и общедоступной карты IT-контура компании не существовало.
По итогам 10 встреч команды KT.Team и EKF совместно построили карту интеграций, актуальную на момент начала проекта, объединив и обогатив локальные схемы, ранее составленные сотрудниками EKF.
Сформировав общую картину IT-контура, ключевые IT-специалисты EKF получили идентичное понимание того, как выглядит IT-ландшафт компании и какие в нём есть потенциальные проблемы — в целом по компании, а не только по отдельным областям.
Созданная схема помогла зафиксировать то, что осложняет процесс обмена данными:
- существует единая точка отказа для клиентских сервисов (портал дистрибуторов, электронный каталог и др.);
- данные дублируются в нескольких системах и проксируются (т. е. система выступает в качестве посредника при передаче информации между другими системами), единая зона ответственности за домен информации отсутствует;
- основная ERP-система перегружена, в том числе задачами по загрузке данных, за счёт чего возникают ошибки и замедление в выгрузке данных;
- для разных систем и кейсов действуют разные механизмы обмена — это повышает сложность поддержки интеграций и работы с инцидентами, учитывая масштабы IT-контура;
- ввиду сильной связанности систем некоторые бизнес-процессы в одних системах невозможно реализовать в случае недоступности других систем (например, дистрибутор не может оформить заказ, когда недоступна ERP).
По итогам разбора и фиксации as is подтвердилась зависимость IT-контура от центральных систем. Сложность текущих интеграций привела к тому, что заменить любой из центральных элементов было практически невозможно в силу высокого риска утраты данных и потери работоспособности всего IT-контура. При такой замене пришлось бы учесть сотни нюансов имеющихся интеграций.
Результат 3: спроектировали новую карту интеграций со слабой связанностью и высокой отказоустойчивостью
Ещё на ранних этапах общения с KT.Team команда EKF рассказала о ряде распространённых кейсов из своей практики, которые ей приходилось регулярно отрабатывать. Например, если по какой-либо причине была недоступна ERP, дистрибуторы не могли сделать заказ на портале, т. к. не видели ассортимент.
Подобные проблемы можно предотвратить с помощью асинхронного обмена данными и разделения хранилищ для разных типов информации.
Новая схема интеграций была спроектирована в соответствии с этими принципами. Для каждой из систем определены домены — зоны её ответственности — и типы данных, источником которых она является.
Информация передаётся асинхронно: сначала — в слой хранилища, затем — в систему-получатель. Таким образом удалось избавиться от взаимной зависимости систем, входящих в IT-контур.
Проектируя новый IT-контур совместно с командой EKF, мы проговаривали, как именно будет организовано хранение данных, как будут разделены микросервисы и как будет выстроено их взаимодействие.
- С систем снята функция взаимной передачи данных (в том числе посреднической), как результат — многократно ускоряется выгрузка обновлений, сокращается лаг между обновлением информации в системе-источнике и её загрузкой в системы-потребители.
- Системы мониторинга и логирования, входящие в ESB, позволяют фиксировать возникающие инциденты (что и в какой момент случилось с данными) и оперативно сообщать об их появлении сотрудникам технической поддержки. Это обеспечивает возможность своевременной отработки обнаруживаемых неполадок.
- Загрузка и выгрузка данных происходит по триггерам или с установленной частотой (в зависимости от бизнес-процесса). Путь каждого сообщения отслеживается автоматически — информация не будет потеряна.
На этом же этапе команда консультантов:
- уточнила для IT-специалистов заказчика требования к самостоятельности сервисов (почему они сформулированы именно так; как самостоятельность сервисов отразится на бизнес-процессах компании и загруженности IT-специалистов);
- составила пошаговое описание процесса трансформации каждого из коннекторов и потоков с указанием причин всех описываемых изменений и ожидаемого эффекта вследствие их реализации;
- разъяснила схему логирования, организации мониторинга и технической поддержки.
В консалтинговом отчёте расписаны принципы мониторинга состояния систем и потоков, механизм оповещения о проблемах, а также перечень информации, отправляемой iT-специалистам для исправления ошибок. Специалисты EKF получили общее для всех команд представление, как будет работать IT-контур, каким образом команды будут узнавать об ошибках и как будут сохраняться недоставленные сообщения.
Результат 4: предоставили сравнение четырёх ESB-решений, что позволило клиенту выбрать систему по ключевым для него параметрам
Команда KT.Team подготовила сравнительный анализ инструментов, с помощью которых можно настроить нужную клиенту интеграцию. На первом этапе сравнили четыре решения: DATAREON, Mule, Talend, WSO2 — по 50 ключевым параметрам, в числе которых: язык разработки адаптеров, наличие библиотеки готовых коннекторов, отказоустойчивость, поддержка разнообразных форматов и протоколов, распределение ролей и доступов, возможности масштабирования и т. д.
На втором этапе выставили балльную оценку каждому из параметров у двух приложений-финалистов. По общему рейтингу для реализации проекта был выбран инструмент Mule.
Результат 5: разделили процесс внедрения ESB-слоя на этапы с понятной длительностью и ценностью каждого из них
Команда KT.Team разработала дорожную карту внедрения ESB-слоя с указанием обоснованной длительности всех этапов в часах — для каждого коннектора и потока по отдельности. Внедрение разделили на несколько этапов, по итогам каждого из которых EKF получает понятную ценность и работающий IT-контур. При планировании этапов внедрения учитывали возможности внутренней команды EKF и оценивали бюджет на привлечение аутсорс-команд.
Этапы определены так, чтобы ввод каждого из них был безопасен для IT-контура компании и предыдущих внедрённых потоков.
Трудоёмкость каждого этапа указана в часах — EKF может сравнить эту оценку с предложениями других интеграторов и выбрать подходящего подрядчика.
Совместно с командой EKF мы выделили ключевой этап, к моменту реализации которого внедрение шины сходится с ROI от внедрения. Для этого мы обозначили блок интеграций, критически важных для основных бизнес-процессов, изменение которых сразу принесёт ощутимую ценность.
Это позволило команде EKF определить необходимый бюджет и приоритеты выполнения дальнейших работ.
Итоги
- IT-специалисты EKF совместно с консультантами KT.Team перевели в формат сервисной карты понимание текущей архитектуры.
- Синхронизировано понимание команды о том, как и почему будет меняться архитектура интеграций.
- Команда знает, какими этапами будет внедряться ESB и какую ценность EKF получает на каждом из них.
- Команда EKF определила необходимый бюджет и приоритеты выполнения дальнейших работ.
- Внедрение ESB-слоя начато двумя командами: EKF и KT.Team.
